講到監控，Prometheus 應該算是最常被提及的其中一個工具，它是一套開源的監控與警報系統，最早由 SoundCloud 開發，並在 2016 年進入 CNCF 孵化器，後來於 2018 年畢業。

架構

那麼，Prometheus 究竟是做什麼用的呢？讓我們來看看這張來自官方文件的架構圖：

本體

Prometheus 的本體主要包含三個部分：

• Retrieval 代表的是它蒐集資料的元件，我們在架設 Prometheus 的時候需要設定他要從那些地方，如何去蒐集指標。
• TSDB 是 time series database 的縮寫，裡面存放的就是 Prometheus 收集來的各項數據，並且包含了時間戳的資訊，以方便我們根據時間查詢。
• HTTP server 讓我們可以透過 HTTP 請求，使用 PromQL （類似 SQL，查詢 Prometheus 的資料用的）去查詢它收集到的指標。並且它本身也有提供一個簡易的 UI 介面可以視覺化目前收集的資料，可是在這部分，比較常見的做法應該還是使用 Grafana 來建立儀錶板，預計後面會提到。

資料來源

Prometheus 採用 pull-based 的設計，也就是說並非由我們主動提供數據給 Prometheus server，而是我們在服務上面提供取得指標的方法（通常是透過對 /metrics 發 GET 請求），然後再由 Prometheus 採集指標。在官方文件可以看到已經有許多現成的 exporter，像是昨天提到的需要收集硬碟的使用率，就可以透過官方的 node exporter 做到。

然而在某些情況下，我們可能沒辦法提供一個可以拉取的介面給 Prometheus，這時候就需要主動推送指標給 Pushgateway，讓他暫存這些指標，然後再由 server 去採集這些指標收進 TSDB 裡面。具體的應用場景可以參考官方文件的分析。

Alertmanager

警報也是監控系統裡面很重要的一環，Prometheus 裡面就有提供一個專門做警報的元件，稱為 Alertmanager，它可以收集從 Prometheus server 送過來的警報，再依據我們設立的規則分配至像是 email 或是 slack 等地方。

指標

在 Prometheus 裡面，所有的資料都會被儲存為 time series，也就是說每一筆資料都會配上一個時間戳。而指標除了儲存單個數字以外，還可以在上面加上標籤 (label) 以幫助我們替指標分類，舉昨天談到的黃金訊號之一的延遲來說好了，今天我們紀錄了 HTTP 請求的處理時間，我們來可以替它加上像是 status code、URL 等等的標籤，就可以幫助我們分離成功跟失敗的請求，更好地反應出服務現在的狀態。

小結

今天打的內容比我想像中的還要少不少...本來還希望可以把 Prometheus 跟一些其他常用的工具做一些比較的，像是跟 InfluxDB (TICK stack)，或是 Thanos、Cortex 之類的解決方案；也有打算來談談有關 OpenTelemetry 與監控生態圈的關係，或者說規範這件事對於軟體開發的影響。

無奈於自身實務經驗實在是不足，我就先將一些我看到的參考資料列在下方，希望有朝一日有機會可以補足這份遺憾吧。

參考資料

• OpenTelemetry 正式釋出第一版規範
• Time Series Database Comparison
• Prometheus vs. InfluxDB: A Monitoring Comparison
• How the Cortex and Thanos projects collaborate to make scaling Prometheus better for all
• Introduction to InfluxData’s InfluxDB and TICK Stack